AWS KMS（Key Management Service）是 AWS 管理加密金鑰的服務。S3、EBS、RDS 勾選「啟用加密」之後，資料雖然加密了，要保護的對象卻換成了金鑰：金鑰存在哪裡、誰可以用它解密、用過的紀錄在哪裡、外洩時怎麼停用，這些由 KMS 負責。

需要保護的不只加密金鑰。資料庫密碼、API 金鑰這類應用程式要讀取的機密，以及 HTTPS 用的 TLS 憑證，AWS 各有對應的服務：

這篇以一個訂單系統準備接受資安稽核為例。系統的資料放在 S3、EBS 與 RDS，稽核清單依序要求：資料要加密、只有特定的人能解密、備份要能在 DR 帳號還原、資料庫密碼不能寫在程式裡、網站要使用 HTTPS。每一項對應一個服務或功能。

🔒 資料加密：S3、EBS、RDS 的靜態加密

用途：儲存媒體、備份或 snapshot 外流時，沒有金鑰的人讀不到資料內容。

加密分成兩個位置：傳輸中（in transit）保護資料在網路上傳送的過程，做法是 TLS（HTTPS）；靜態（at rest）保護存在磁碟、資料庫、S3 裡的資料。稽核清單的第一項是靜態加密。

靜態加密依「誰來加密」分成兩種：server-side 是資料送到服務後，由服務加密再寫入，應用程式不需要修改；client-side 是應用程式在送出之前自己加密，服務收到的已經是密文。S3 是考題最常出現加密選項的服務，物件寫入時有四種方式，差別在金鑰由誰保管、在哪裡加密：

這個訂單系統要求「只有特定的人能解密」，所以選 SSE-KMS。使用 SSE-KMS 時，每個物件的讀寫都會呼叫 KMS；物件數量很多時，可能碰到 KMS 的請求上限，費用也會增加。啟用 S3 Bucket Key 後，S3 改以 bucket 層級的金鑰產生各物件的 data key，大幅減少對 KMS 的呼叫。

EBS 與 RDS 的加密要在建立時決定。已經建立、未加密的 EBS volume 無法直接改為加密，要先拍 snapshot、複製時加密，再用加密的 snapshot 建立新 volume；帳號層級可以設定「新的 EBS volume 預設加密」，避免之後再補救。

選了 SSE-KMS 之後，下一個問題是：用哪一種 KMS 金鑰。

🔑 選擇金鑰：KMS 的三種金鑰

用途：決定金鑰由誰管理，以及能不能自己控制權限、輪替與停用。

KMS 金鑰的原始內容（key material）保存在 KMS 的 HSM（hardware security module，專門保管金鑰的硬體）中，永遠不會以明文離開 KMS；使用者只能透過 API 請 KMS 用這把金鑰加密或解密，每一次使用都會記錄在 CloudTrail。KMS 的金鑰依「由誰管理」分成三種：

只要「資料有加密」，AWS owned 或 AWS managed key 就夠了；需要控制誰能使用金鑰、跨帳號共用、自訂輪替週期或隨時停用時，要用 customer managed key。這個訂單系統兩者都需要，所以建立 customer managed key。

輪替時，KMS 產生新的 key material 用於之後的加密，但保留舊的 key material，先前加密的資料仍然可以解密，不需要重新加密。也可以把自己產生的 key material 匯入 KMS（imported key material），由自己決定到期時間或刪除，但這類金鑰不支援自動輪替。

大量資料怎麼加密：envelope encryption

KMS 的 Encrypt API 一次最多只能加密 4 KB 的資料：把數 GB 的檔案透過網路送進 KMS 加密，又慢又會受到 API 呼叫上限的限制。S3、EBS、RDS 實際使用的方式是 envelope encryption（信封加密）：

加密：
1. 呼叫 KMS 的 GenerateDataKey，取得一把 data key 的兩個版本：明文版和被 KMS 金鑰加密過的版本
2. 在本機用明文的 data key 加密大量資料
3. 從記憶體刪除明文的 data key，把「加密過的 data key」和密文存在一起

解密：
1. 把「加密過的 data key」送給 KMS 解密，取回明文的 data key
2. 在本機用它解密資料

KMS 的金鑰只負責加解密那把很小的 data key，大量資料的加解密都在本機進行。使用 S3、EBS、RDS 的 server-side 加密時不會直接看到這個流程；自己做 client-side 加密時就要用這個方式，AWS Encryption SDK 已經把流程包裝好。

金鑰建好了，接著要設定誰可以使用它。

🧾 誰能用金鑰、能用到哪裡：key policy、跨帳號與跨 Region

用途：限制只有指定的身分能用金鑰解密，並讓加密的備份能在其他帳號或 Region 還原。

每一把 KMS 金鑰都有一份 key policy，這是控制金鑰存取的主要依據。和其他服務不同，只有 IAM policy 不夠：key policy 必須先允許，IAM policy 才會生效。預設的 key policy 允許金鑰所在的帳號管理這把金鑰，帳號內的 IAM policy 因此可以授權使用者使用它。

稽核清單要求備份能在 DR 帳號還原。EBS snapshot 以生產帳號的 customer managed key 加密，DR 帳號要用這把金鑰解密，兩邊都要允許：

以 AWS managed key（aws/ebs）加密的 snapshot 無法分享給其他帳號，因為它的 key policy 不能修改，沒辦法授權對方。這時要先把 snapshot 複製一份、改用 customer managed key 加密，再分享複製出的 snapshot。

KMS 金鑰也屬於單一 Region。把加密的 EBS snapshot 或 AMI 複製到另一個 Region 時，要指定目的 Region 的 KMS 金鑰，資料會以新金鑰重新加密。如果同一份資料要在多個 Region 加解密，例如 client-side 加密的資料會複製到其他 Region，可以使用 multi-Region key：多個 Region 各有一把金鑰 ID 與 key material 都相同的金鑰，在 A Region 加密的資料可以直接在 B Region 解密。

金鑰無法立即刪除：排定刪除後有 7 到 30 天的等待期，期間可以取消。刪除後，用這把金鑰加密的資料就再也無法解密，等待期是為了防止誤刪。不確定時可以先「停用」金鑰，暫時無法使用，隨時可以恢復。

資料與備份處理完，稽核清單的下一項是應用程式裡的資料庫密碼。

🗝️ 資料庫密碼：Secrets Manager 與 Parameter Store

用途：讓密碼不再出現在程式碼與設定檔中，並能定期自動更換。

這個訂單系統的資料庫密碼原本寫在設定檔裡，任何能讀程式碼的人都看得到，也很少有人更換。資料庫密碼、API 金鑰這類應用程式要讀取的機密，存放在 Secrets Manager 或 Parameter Store：應用程式啟動時以 IAM role 的權限向服務讀取，程式碼和設定檔裡不再出現密碼。兩者都用 KMS 加密，差別主要在輪替：

需要自動輪替密碼（尤其是 RDS 密碼）時用 Secrets Manager；只是存放設定值或不需要輪替的機密，Parameter Store 較便宜。

稽核清單的最後一項是傳輸加密。

📜 HTTPS 憑證：ACM

用途：免費取得 HTTPS 需要的 TLS 憑證，並自動續期，不必追蹤到期日。

AWS Certificate Manager（ACM） 免費提供公開的 TLS 憑證，可以直接掛在 ALB、CloudFront、API Gateway 上，到期前自動續期。兩個常考的細節：

• CloudFront 使用的憑證必須在 us-east-1 申請。CloudFront 是全球服務，只讀取 us-east-1 的 ACM 憑證；其他 Region 的服務（例如 ALB）使用同一個 Region 的憑證
• 自動續期適用於 ACM 整合的服務。自己安裝在 EC2 上的 Web 伺服器，憑證的安裝和更新要自行處理

🛡️ 法規要求獨占的硬體：CloudHSM

用途：金鑰必須存放在只供自己使用、由自己獨自控制的硬體時使用。

KMS 的 HSM 由 AWS 管理、多個客戶共用（金鑰彼此隔離），一般的稽核要求用 KMS 就能滿足。有些金融或政府法規更嚴格，要求金鑰存放在只供自己使用的硬體裡，而且由公司獨自控制。

AWS CloudHSM 在 VPC 中提供單一租戶的 HSM：AWS 負責硬體的運作，HSM 內的使用者與金鑰完全由客戶管理，AWS 無法取得金鑰。代價是可用性要自己規劃（在多個 AZ 建立 HSM 組成叢集），金鑰遺失時 AWS 也無法協助還原。

需要 CloudHSM 的金鑰控制，又想讓 S3、EBS 等服務照常整合加密時，可以建立 KMS 的 custom key store：KMS 金鑰的 key material 改放在自己的 CloudHSM 叢集中，各服務仍透過 KMS 使用它。

✅ 稽核清單與對應做法

摘要：加密之後要保護的是金鑰，KMS 負責管理金鑰並記錄每一次使用。

🧠 AI 出題

問題 1

某公司的訂單服務部署在 Amazon ECS 上，以帳號密碼連線到 Amazon RDS for MySQL，密碼目前寫在容器映像檔的設定檔中。新的稽核要求規定：資料庫密碼必須每 30 天自動更換一次，且不得出現在程式碼、映像檔或設定檔中。應用程式仍維持以帳號密碼的方式連線資料庫。

哪一個方案的維運負擔最低（LEAST operational overhead）？

• A. 把密碼存入 Parameter Store 的 SecureString，以 EventBridge 排程每 30 天觸發自行撰寫的 Lambda 更新密碼與參數
• B. 用 AWS KMS 的 customer managed key 加密設定檔中的密碼，並啟用這把金鑰的自動輪替，輪替期間設為 30 天
• C. 把密碼存入 Secrets Manager 並啟用 30 天的自動輪替，讓應用程式在連線前從 Secrets Manager 取得密碼
• D. 改用 RDS 的 IAM database authentication，讓應用程式以 ECS task role 產生驗證 token，每次連線時取代原本的密碼

問題 2

某公司在生產帳號中有一批 EBS snapshot，建立時使用預設的 AWS managed key（aws/ebs）加密。災難復原計畫要求把這些 snapshot 分享給同一個 AWS Organizations 中的 DR 帳號，讓 DR 帳號能以這些 snapshot 建立 EBS volume，而且資料在整個過程中都必須維持加密。直接分享時，主控台顯示無法分享。

哪兩項步驟的組合能讓 DR 帳號使用這些 snapshot？（選擇兩項）

• A. 在生產帳號建立 customer managed key，並在它的 key policy 中允許 DR 帳號使用這把金鑰
• B. 把 snapshot 複製一份並在複製時改用 customer managed key 加密，再分享複製出的 snapshot
• C. 修改 aws/ebs 金鑰的 key policy，加入允許 DR 帳號使用這把金鑰的陳述，再直接分享原本的 snapshot
• D. 把每個 snapshot 複製一份並在複製時選擇不加密，分享給 DR 帳號後，再由 DR 帳號自行加密
• E. 在 DR 帳號建立具有 kms:Decrypt 權限的 IAM role，讓生產帳號以這個 role 的身分分享 snapshot

問題 3

某研究機構的應用程式在上傳 Amazon S3 之前，必須在 EC2 上先把每個 1～5 GB 的影像檔加密，加密金鑰要由 AWS KMS 的 customer managed key 控制。開發人員直接對每個檔案呼叫 KMS 的 Encrypt API，結果全部失敗，錯誤訊息指出輸入的資料超過大小上限。

哪一個方案最符合成本效益（MOST cost-effective）？

• A. 向 AWS 申請提高 KMS 的請求速率配額，並把 Encrypt 的呼叫改為非同步執行，避免大型檔案的請求互相阻塞
• B. 把每個檔案切成 4 KB 的區塊，逐一呼叫 KMS 的 Encrypt API 加密，再把所有加密後的區塊合併成單一檔案上傳
• C. 改為直接上傳未加密的檔案到 S3，並在 bucket 啟用以這把 customer managed key 進行的 SSE-KMS 預設加密
• D. 對每個檔案呼叫 GenerateDataKey，在 EC2 上用明文 data key 加密檔案，再把加密的 data key 一起存放

問題 4

某銀行要把核心系統的資料存放在 Amazon S3 與 Amazon EBS，並使用 server-side 加密。金融法規要求：加密金鑰必須存放在只供該銀行使用的單一租戶硬體安全模組中，由銀行獨自控制，AWS 人員無法取得金鑰；同時希望 S3 與 EBS 仍能以原生的整合方式加密，不改寫應用程式。

哪一個方案最符合法規要求（MOST secure）？

• A. 在 KMS 建立 customer managed key 並匯入銀行自行產生的 key material，再以這把金鑰為 S3 與 EBS 設定 server-side 加密
• B. 建立 AWS CloudHSM 叢集並以它建立 KMS custom key store，在其中建立 KMS 金鑰，再用於 S3 與 EBS 的 server-side 加密
• C. 在 KMS 建立 customer managed key，在 key policy 中拒絕所有 AWS 服務主體，再用這把金鑰為 S3 與 EBS 設定加密
• D. 建立 AWS CloudHSM 叢集，並在 S3 bucket 與 EBS volume 的加密設定中直接指定 CloudHSM 叢集 ID 作為金鑰來源

問題 5

某公司把靜態網站放在 Amazon S3，透過 Amazon CloudFront 對外提供，並要使用自訂網域 www.example.com 與 HTTPS。團隊在 eu-west-1 的 ACM 申請並驗證了這個網域的公開憑證，但在 CloudFront distribution 的設定中找不到這張憑證。公司希望憑證能自動續期，不必人工追蹤到期日。

哪一個方案能以最少的維運工作解決這個問題？

• A. 向第三方憑證機構購買 www.example.com 的憑證，上傳到 IAM 的憑證儲存區，再把它指定給 CloudFront distribution
• B. 把 CloudFront distribution 的 Region 設定改為 eu-west-1，讓它讀取同一個 Region 的 ACM 憑證，再指定這張憑證
• C. 在 us-east-1 的 ACM 以 DNS 驗證申請 www.example.com 的公開憑證，再指定給 CloudFront distribution
• D. 在 us-east-1 的 ACM 以 email 驗證申請 www.example.com 的公開憑證，再指定給 CloudFront distribution

💡 解答

1. C

Secrets Manager 對 RDS 的 secret 內建自動輪替：設定 30 天的輪替週期後，Secrets Manager 會自動在資料庫中更換密碼並更新 secret，不需要自己撰寫輪替程式。應用程式以 ECS task role 的權限在連線前讀取密碼，程式碼、映像檔和設定檔裡都不再有密碼。

A 能達到同樣的效果，但輪替的 Lambda 要自己撰寫並維護，包括更新資料庫密碼、處理失敗的情況，維運負擔高於內建的輪替。B 是常見的誤解：KMS 的金鑰輪替更換的是加密用的 key material，資料庫的密碼本身沒有任何改變；而且密碼仍然存放在設定檔中。D 確實能讓應用程式不再保存密碼，但它改變了連線的驗證方式，違反「仍以帳號密碼連線」的限制。

2. A、B

以 AWS managed key 加密的 snapshot 無法分享給其他帳號，因為這種金鑰的 key policy 不能修改，沒辦法授權其他帳號使用。所以要分兩步：先建立 customer managed key，在 key policy 中允許 DR 帳號使用；再把 snapshot 複製一份，複製時改用這把金鑰加密，然後把新的 snapshot 分享給 DR 帳號。DR 帳號有了金鑰的使用權限（DR 帳號內的使用者也要有對應的 IAM 權限），就能以它建立 EBS volume，資料全程都是加密的。少了任何一步都做不到。

C 是誤解：AWS managed key 的 key policy 由 AWS 管理，使用者只能查看，不能修改。D 是不存在的做法：加密的 snapshot 在複製時不能改為不加密，複製出的 snapshot 一定仍是加密的；就算做得到，也違反「全程維持加密」。E 弄反了權限的方向：要授權的是生產帳號的金鑰使用權，DR 帳號自己的 IAM role 拿不到 aws/ebs 的權限，也不能代替生產帳號分享 snapshot。

3. D

KMS 的 Encrypt 一次最多只能加密 4 KB 的資料，這是 API 的設計限制，不能調高。大型檔案要用 envelope encryption：呼叫 GenerateDataKey 取得明文與加密過的 data key，在 EC2 上用明文 data key 加密整個檔案，再把加密過的 data key 和檔案存在一起。每個檔案只需要呼叫 KMS 一次，費用最低，金鑰仍由 customer managed key 控制。

A 是誤解：失敗的原因是單次輸入超過 4 KB 的上限，與請求速率無關，提高配額也不會改變這個上限。B 技術上可行，但 5 GB 的檔案會切成上百萬個區塊，每個區塊都要呼叫一次 KMS，速度很慢，KMS 的請求費用也會非常高。C 改成 server-side 加密，檔案以未加密的狀態離開 EC2，違反「上傳之前就要加密」的要求。

4. B

KMS custom key store 以客戶自己的 CloudHSM 叢集存放 key material：CloudHSM 是單一租戶的硬體，HSM 內的金鑰由銀行獨自管理，AWS 無法取得。在 custom key store 中建立的 KMS 金鑰，仍然可以用於 S3 與 EBS 的原生 server-side 加密，不需要改寫應用程式，兩項要求都滿足。

A 的 imported key material 由銀行產生，但匯入後仍存放在 KMS 共用的 HSM 中，不符合單一租戶硬體的要求。C 的 key policy 只控制誰可以使用金鑰，key material 仍在 KMS 共用的 HSM 中；拒絕 AWS 服務主體還會讓 S3 與 EBS 無法用它加密。D 是不存在的設定：S3 與 EBS 的 server-side 加密只能使用 KMS 的金鑰，不能直接指定 CloudHSM 叢集，必須透過 custom key store。

5. C

CloudFront 是全球服務，只能使用 us-east-1 的 ACM 憑證，所以 eu-west-1 申請的憑證不會出現在選單中。在 us-east-1 的 ACM 重新申請同一個網域的憑證，就能在 distribution 中指定。以 DNS 驗證時，只要驗證用的 CNAME 記錄留在 DNS 中，ACM 就會在到期前自動續期，完全不需要人工處理；ACM 公開憑證本身也不收費。

A 可以運作，CloudFront 也支援 IAM 憑證儲存區中的憑證，但第三方憑證不會自動續期，每次到期都要重新購買並上傳，違反「自動續期」的要求。B 是不存在的設定：CloudFront distribution 沒有 Region 可以選擇。D 只差在驗證方式，是最容易選錯的干擾項：以 email 驗證的憑證，續期時 ACM 會寄信給網域的聯絡人，必須有人點選確認才會完成續期，沒有人處理就會過期，不符合「不必人工追蹤」。